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Beschreibung 

Konf igurierbarer Hardware -Block 

5 Die vorliegende Erfindung betrifft eine Vorrichtung gemafi dem 
Oberbegriff des Patentanspruchs 1, d.h. einen konfigurier- 
baren Hardware-Block, der dazu ausgelegt ist, abhangig von 
seiner Konf iguration in einer Speichereinrichtung gespei- 
cherte Daten auszulesen, die ausgelesenen Daten arithmetisch 
10 und/oder logisch zu verarbeiten, und das Ergebnis der Ver- 
arbeitung reprasentierende Daten in die Speichereinrichtung 
^ einzuschreiben. 

Konf igurierbare Hardware-Blocke sind seit langem in einer 
15 Vielzahl von Ausf iihrungsf ormen bekannt. Zu ihnen zahlen unter 
anderem die sogenannten feldprogrammierbaren Logikbausteine 
wie PALs (programmable array logic) , GALs (Generic array 
logic) etc . 

20 Konf igurierbare Hardware-Blocke konnen auch in programm- 

gesteuerten Einheiten zum Einsatz kommen; es ist bekannt, sie 
in den sogenannten >S<putern einzusetzen. 

^ ' Programmgesteuerte Einheiten wie Mikroprozessoren, Mikro- 
25 controllern etc. waren bis vor kurzem nahezu ausschlieftlich 
nach dem bekannten Von-Neumann-Modell konzipiert. Zwar wurde 
(beispielsweise im Harvard-Modell ) davon abgeruckt, getrennte 
Code- und Datenspeicherbereiche vorzusehen, doch erfolgt die 
Ausfuhrung der Befehle (der damit verbundenen Aktionen bzw. 
30 Operationen) selbst heutzutage noch fast ausschlielilich rein 
sequentiell . 

Die sequentielle Abarbeitung der Befehle begrenzt die maxi- 
male Rate, mit welcher diese abgearbeitet werden konnen. 
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Eine besonders hohe Rate lafit sich durch die sogenannten 
RISC-Prozessoren erzielen. Diese weisen einen reduzierten 
Befehlssatz auf und ermoglichen es dadurch, die Mikropro- 
gramme, unter Verwendung welcher die abzuarbeitenden Befehle 
ublicherweise decodiert und ausgefuhrt werden, durch fest 
verdrahtete Hardware zu ersetzen. Dies wiederum gestattet es, 
besonders schnell und effizient arbeitende Bef ehls-Pipelines 
und Bef ehls-Ausf iihrungseinheiten zu realisieren, so daft im 
Mittel bis zu ein Befehl pro Prozessortakt zur Ausfuhrung 
gebracht werden kann. Wegen der nach wie vor vorhandenen 
Abarbeitungs- und Ergebnissequentialitat kann jedoch auch mit 
RISC-Prozessoren nicht mehr als ein Befehl pro Prozessortakt 
ausgefuhrt werden . 

Eine programmgesteuerte Einheit, in welcher mehr als ein 
Befehl pro Prozessortakt abgearbeitet werden kann, ist der 
vorstehend bereits erwahnte >S<puter. Ein solcher >S<puter 
ist beispielsweise in der EP 0 825 540 Al beschrieben. 

Der grundlegende Aufbau eines >S<puters ist in Figur 3 ge- 
zeigt und wird nachfolgend unter Bezugnahme hierauf beschrie- 
ben . 

Der Vollstandigkeit halber sei bereits an dieser Stelle dar- 
auf hingewiesen, dafi der >S<puter, insbesondere dessen die 
Befehle abarbeitende Teil nur teilweise (nur so weit es fur 
die vorliegend naher betrachteten konf igurierbaren Hardware- 
Blocke von Bedeutung ist) dargestellt und beschrieben ist. 

Der >S<puter gemafl Figur 3 umfalit eine Vordecodier-Einheit 
(predecode unit) 1, einen Instruktions-Puf f er (instruction 
buffer) 2, eine Decodier-, Umbenennungs- und Lade-Einheit 
(decode, rename & load unit) 3, eine s-Paradigmen-Einheit (s- 
unit) 4, einen Daten-Cache (data cache) 5, und eine Speicher- 
Schnittstelle (memory interface) 6, wobei die s-unit 4 aus 
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einem Strukturprogrammier-Puf f er (programmable structure 
buffer) 41, einer Funktionseinheit mit programmierbarer 
Struktur (functional unit with programmable structure) 42, 
einem Integer /Adreftinstrukt ions-Puffer (integer /address 
5 instruction buffer) 43 und einem Registerblock (integer 
register file) 44 besteht. 

Die Besonderheit des >S<puters besteht insbesondere in dessen 
s-unit 4, genauer gesagt in der functional unit 42 derselben. 

10 Die functional unit 42 ist eine strukturierbare Hardware, die 
basierend auf vom >S<puter auszuf uhrenden Instruktionen oder 

i Instruktionsfolgen dynamisch so konf igurierbar ist, daft sie 
die durch die Instruktionen oder Instruktionsfolgen vorgege- 
benen Aktionen bzw. Operationen ausfuhren kann. 

15 

Vom >S<puter auszuf uhrende Instruktionen (genauer gesagt 
diese reprasentierende Code-Daten) gelangen aus einem nicht 
gezeigten Speicher liber das memory interface 6 in die pre- 
decode unit 1, wo sie vordecodiert werden; dabei konnen zu 
20 den Code-Daten beispielsweise Inf ormationen hinzugefugt wer- 
den, die die spatere Decodierung in der decode, rename & load 
unit 3 erleichtern. Die Code-Daten gelangen dann uber den 
instruction buffer 2 in die decode, rename & load unit 3, wo 
' * die Ausfuhrung der durch die Code-Daten represent ierten 
25 Instruktionen vorbereitet wird. Diese Vorbereitung umfafit die 
Decodierung der Code-Daten, die Konf igurierung bzw. Struktu- 
rierung der functional unit 42, die Initialisierung bzw. Ver- 
waltung des integer register file 44, und das Starten der 
wunschgemafl konf igurierten functional unit 42. 

30 

Die Strukturierung bzw. Konf igurierung der functional unit 42 
erfolgt unter Verwendung von die gewunschte Konf igurat ion 
reprasentierenden Konf igurat ions-Daten, die von der decode, 
rename & load unit 3 in den programmable structure buffer 41 
35 geschrieben werden. Diese, die gewunschte Konf igurat ion 
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reprasentierenden Konf igurations-Daten werden in cler decode, 
rename & load unit 3 kreiert; sie konnen aber auch schon in 
codierter Form in den Code-Daten enthalten sein. 

5 Die functional unit 42 ist dazu ausgelegt, Daten aus dem 
register file 44 und/oder dem data cache 5 auszulesen, die 
ausgelesenen Daten arithmetisch und/oder logisch zu verarbei- 
ten, und das Ergebnis der Verarbeitung reprasentierende Daten 
in das register file 44 und/oder den data cache 5 einzu- 

10 schreiben; sie (die functional unit 42) ist damit ein konfi- 
gurierbarer Hardware-Block gemafJ dem Oberbegriff des Patent- 

8 anspruchs 1. 

Bei geeigneter Initialisierung des register file 44 und bei 
15 geeigneter Konf igurierung der functional unit 42 hat der 

Betrieb der functional unit 42 die Vornahme von Aktionen bzw. 
Operationen zu Folge, die durch die Ausfuhrung der Instruk- 
tionen, auf der Basis welcher die Initialisierung des 
register file 44 und die Konf igurierung der functional unit 
20 42 erfolgten, zu bewirken sind. 

Die Vornahme der durch die Ausfiihrung von Instruktionen zu 
bewirkenden Aktionen durch eine entsprechend konf igurierte 

i 

Hardware (die functional unit 42) ist bekanntlich bedeutend 
25 schneller als die Ausfiihrung der Instruktionen in den "nor- 
malen" Arithmetisch-Logischen Einheiten (ALUs) von herkomm- 
lichen programmgesteuerten Einheiten, Dies gilt in besonderem 
Malie fur den Fall, daft die Hardware (die functional unit 42) 
so konfiguriert ist, daft durch deren Betrieb ein Ergebnis 
30 erzielbar ist, das der Ausfuhrung mehrerer aufeinan- 

derfolgender Instruktionen (einer mehrere Instruktionen um- 
f assenden Makroinstruktion) entspricht . 
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Bezuglich weiterer Einzelheiten zum Aufbau, cler Funktion und 
der Wirkungsweise von >S<putern wird auf die vorstehend be- 
reits erwahnte EP 0 825 540 Al verwiesen. 

5 Der Vollstandigkeit halber sei angemerkt, daft nicht alle 

Aktionen, die durch die vom >S<puter auszuf iihrenden Instruk- 
tionen zu bewirken sind, durch die functional unit 42 aus- 
fuhrbar sind. Instruktionen wie insbesondere zur Programm- 
ablauf steuerung bzw. Kontrollf lufisteuerung dienende Instruk- 

10 tionen wie beispielsweise Branch-, Jump-, No-Operation-, 

Wait- und Stop-Instruktionen werden in der Regel auf herkomm- 

' liche Art und Weise ausgefuhrt werden. 

Nichtsdestotrotz kann durch die Verwendung konf igurierbarer 
15 Hardware-Blocke wie der functional unit 42 im allgemeinen 

eine hohere Anzahl von durch auszuf uhrende Befehle zu bewir- 
kenden Aktionen pro Zeiteinheit ausgefuhrt werden als es mit 
herkommlichen prograramgesteuerten Einheiten der Fall ist, 
also mehr als ein Befehl pro Prozessortakt abgearbeitet wer- 
20 den. 

Allerdings gibt es auch Anwendungen, bei denen die Anzahl der 
pro Zeiteinheit ausfuhrbaren Aktionen durch das Vorsehen von 
Hardware-Blocken der vorstehend beschriebenen Art nicht stei- 
25 gerbar ist . 

Der vorliegenden Erfindung liegt daher die Aufgabe zugrunde, 
den Hardware-Block gemali dem Oberbegriff des Patentanspruchs 
1 derart weiterzubilden, daft dieser flexibler und/oder uni- 
30 verseller einsetzbar ist als es bislang der Fall ist. 



Diese Aufgabe wird er f indungsgemafi durch die im kennzeichnen- 
den Teil der Patentanspruchs 1 beanspruchten Merkmale gelost. 
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Demnach ist vorgesehen, daft der Hardware-Block in die Lage 
versetzbar ist, mit externer Hardware zu interagieren. 

Dies steigert die Leistungsf ahigkeit und erweitert die Ver- 
5 wendungsmoglichkeiten des Hardware-Blocks; der Hardware-Block 
ist dadurch flexibler und universeller einsetzbar als es bei 
herkommlichen Hardware-Blocken der betrachteten Art der Fall 
ist . 

10 Vorteilhafte Weiterbildungen der Erfindung sind den Unter- 
anspriichen, der folgenden Beschreibung und den Figuren ent- 
nehmbar. 

Die Erfindung wird nachfolgend anhand eines Ausfiihrungs- 
15 beispiels unter Bezugnahme auf die Figuren naher erlautert. 
Es zeigen 

Figur 1 den prinzipiellen Aufbau des nachfolgend naher be- 
schriebenen Hardware-Blocks, 



20 



25 



Figur 2 den Hardware-Block gemaft Figur 1 in einem fur eine 
bestimmte Anwendung strukturierten Zustand, und 

Figur 3 den prinzipiellen Aufbau eines >S<puters. 



Der nachfolgend naher betrachtete Hardware-Block ist ein kon- 
f igurierbarer Hardware-Block, der dazu ausgelegt ist, abhan- 
gig von seiner Konf igurierung in einer Speichereinrichtung 
gespeicherte Daten auszulesen, die ausgelesenen Daten arith- 

30 metisch und/oder logisch zu verarbeiten und das Ergebnis der 
Verarbeitung reprasentierende Daten in die Speichereinrich- 
tung einzuschreiben; er ist daruber hinaus in die Lage ver- 
setzbar, selbstandig mit externer Hardware zu interagieren 
und wird dadurch zu einem Hardware-Block, welcher sowohl 

35 innerhalb programmgesteuerter Einheiten (beispielsweise als 
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functional unit eines >S<puters) oder sonstiger Einrichtungen 
als auch als eigenstandige (ohne liber- oder nebengeordnete 
Steuereinrichtungen auskoramende) Einheit flexibel und uni- 
versell verwendbar ist und deshalb im folgenden als UCB 
(Universal Configurable Block) bezeichnet wird. 

Die Speichereinrichtung, aus welcher der UCB Daten ausliest 
und in welche der UCB Daten einschreibt, kann innerhalb oder 
aufterhalb des UCB vorgesehen sein; im vorliegend betrachteten 
Beispiel wird die Speichereinrichtung durch das register file 
44 des >S<puters gemafi Figur 3 gebildet. 

Die Schreib- und Lesezugriffe des UCB auf die Speicher- 
einrichtung erfolgen vorzugsweise getaktet. Der UCB selbst 
ist ein asynchrones Schaltnetz zwischen den Aus- und Eingan- 
gen der Speichereinrichtung; die Bestandteile des UCB sind 
asynchron miteinander gekoppelt. 

Die speichereinrichtung ist vorzugsweise von aulierhalb des 
UCB vor Inbetriebnahme desselben initialisierbar ; denkbar 
ware auch, daft der UCB die Initialisierung der Speicher- 
einrichtung selbst veranlaBt oder durchfuhrt. 

Der prinzipielle Aufbau eines UCB ist in Figur 1 gezeigt. 

Der gezeigte UCB weist eine oder mehrere arithmetische Ein- 
heiten AU1, AU2 , eine oder mehrere Vergleichs-Einheiten eines 
ersten Typs CUA, einen oder mehrere Multiplexer eines ersten 
Typs MUXA1, MUXA2, MUXA3 , einen oder mehrere Multiplexer 
eines zweiten Typs MUXB, einen oder mehrere Demultiplexer 
DEMUX, eine oder mehrere Taktgenerierungs-Einheiten TGU und 
eine oder mehrere Signaiisierungs-Einheiten SU auf, wobei die 
Signalisierungs-Einheit SU im betrachteten Beispiel einen 
Multiplexer des ersten Typs MUXA4 und eine Vergleichs-Einheit 
eines zweiten Typs CUB umf aftt . 



GR 98 P 81071 



Die arithmetischen Einheiten AU1, AU2 weisen im betrachteten 
Beispiel zwei Eingangsanschlusse, einen Ausgangsanschlufi und 
einen Steueranschluli auf. Den arithmetischen Einheiten AU1, 
5 AU2 obliegt es, die uber deren Eingangsanschlusse eingegebe- 
nen Eingangssignale arithmetisch und/oder logisch zu verar- 
beiten. Die Operationen, die durch die arithmetischen Einhei 
ten AU1, AU2 ausfuhrbar sind, konnen fest vorgegeben oder 
individuell einstellbar (konf igurierbar ) sein; sie umfassen 

10 insbesondere arithmetische Operationen wie Addition, Subtrak 
tion, Multiplikation, Division etc., logische Verknupf ungen 
wie UND-Verkniipf ungen, ODER-Verkniipf ungen, Invertierung, 
Komplementbildung etc., arithmetische und logische Shift- 
Operationen, und Datentransf ers ( Durchschaltung eines der 

15 eingegebenen Signale zum Ausgangsanschlufi) . Die arithmeti- 
schen Einheiten AU1, AU2 sind nicht mit den Arithmetisch/- 
Logischen Einheiten (ALUs) herkommlicher programmgesteuerter 
Einheiten wie Mikroprozessoren, Mikrocontrollern etc. gleich 
zusetzen; die von ihnen ausfiAhrbaren Operationen sind be- 

20 grenzt, so dafi der Aufbau der arithmetischen Einheiten AU1, 
AU2 vergleichsweise einfach bleiben kann . Ober die Steuer- 
anschltisse der arithmetischen Einheiten AU1, AU2 ist fest- 
legbar, ob die betreffende arithmetische Einheit die Opera- 
tion, zu deren Ausfiihrung sie vorgesehen ist, ausfuhrt oder 

25 nicht. Dies ermoglicht die praktische Umsetzung von Befehlen 
deren Ausfiihrung vom Vorliegen einer bestimmten Bedingung ab 
hangt. Die Bedingung kann beispielsweise der Zustand eines 
bestimmten Flags sein: ist das Flag gesetzt, wird die der 
betreffenden arithmetischen Einheit obliegende Aufgabe (bei- 

30 spielsweise eine Addition) ausgefuhrt, andernfalls nicht 

(oder umgekehrt) . Derartige, nachfolgend als " kondit ionierte 
Befehle" bezeichnete Befehle ermoglichen es, die schwer hand 
habbaren bedingten Sprungbef ehle zu eliminieren; sie werden 
spater noch genauer beschrieben. 



35 
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Die Vergleichs-Einheit des ersten Typs CUA weist im betrach- 
teten Beispiel zwei Eingangsanschlusse und einen Ausgangs- 
anschluft auf . Der Vergleichs-Einheit CUA obliegt es, die an 
deren Eingangsanschlussen anliegenden Signale oder Daten 
5 Vergleichsoperationen zu unterziehen. Die Operationen, die 

durch die Vergleichs-Einheit CUA ausfuhrbar sind, konnen fest 
vorgegeben oder individuell einstellbar ( konf igurierbar ) 
sein; sie umfassen beispielsweise GroBer-, GroBer/Gleich-, 
Kleiner-, Kleiner /Gleich- , Gleich-, und Ungleich-Vergleiche 
10 und Uberprufungen auf wahr (TRUE) und unwahr (FALSE) . Der 
Ausgangsanschluli der Vergleichs-Einheit CUA ist uber den 

m 

■* ^ nachfolgend noch genauer beschriebenen Demultiplexer DEMUX 
mit den Steueranschlussen der arithmetischen Einheiten AU1, 
AU2 verbunden. Vom Ergebnis der in der Vergleichs-Einheit CUA 
15 ausgefiihrten Operation hangt es also ab, ob die arithmeti- 
schen Einheiten AU1, AU2 die Operation, zu deren Ausfuhrung 
sie vorgesehen sind, ausfuhren oder nicht . 

Die Multiplexer des ersten Typs MUXA1, MUXA2, MUXA3 und 
20 MUXA4 , der Multiplexer des zweiten Typs MUXB, und der Demul- 
tiplexer DEMUX dienen zur Auswahl der Daten- und/oder Signal- 
quellen und der Daten- und/oder Signalziele. Genauer gesagt 
^ dienen 

25 - der Multiplexer MUXA1 zur Auswahl der Quellen der den Ein- 
gangsanschlussen der arithmetischen Einheit AU1 zugefuhrten 
Daten und/oder Signale (mogliche Daten- und/oder Signal- 
quellen sind im betrachteten Beispiel das register file 44 
und andere arithmetische Einheiten) , 

30 

- der Multiplexer MUXA2 zur Auswahl der Quellen der den Ein- 
gangsanschlussen der arithmetischen Einheit AU2 zugefuhrten 
Daten und/oder Signale (mogliche Daten- und/oder Signal- 
quellen sind im betrachteten Beispiel das register file 44 
35 und andere arithmetische Einheiten) , 
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- der Multiplexer MUXA3 zur Auswahl der Quellen der den Ein- 
gangsanschlussen der Vergleichs-Einheit CUA zugefuhrten 
Daten und/oder Signale (mogliche Daten- und/oder Signal- 
5 quellen sind im betrachteten Beispiel das register file 44 
und die arithmetischen Einheiten) , 



(6 



- der Multiplexer MUXA4 zur Auswahl der Quellen der den Ein- 
gangsanschllissen der Vergleichs-Einheit CUB zugefuhrten 
10 Daten und/oder Signale (mogliche Daten- und/oder Signal- 

quellen sind im betrachteten Beispiel das register file 44 
und die arithmetischen Einheiten) , 



- der Multiplexer MUXB zur Auswahl der Quellen der dem 
15 register file zugefuhrten Daten und/oder Signale (mogliche 

Daten- und/oder Signalquellen sind im betrachteten Beispiel 
die arithmetischen Einheiten, das register file selbst, und 
(im betrachteten Beispiel uber eine sogenannte Load/Store- 
Pipeline LPL, SPL) die externe Hardware) , 



20 



25 



der Demultiplexer DEMUX zur Auswahl des oder der Ziele fur 
die von der Vergleichs-Einheit CUA ausgegebenen Daten 
und/oder Signale (mogliche Daten- und/oder Signalziele sind 
im betrachteten Beispiel die arithmetischen Einheiten) . 



Die Multiplexer des ersten Typs weisen mehrere Eingangs- 
anschlusse und zwei Ausgangsanschlusse auf, die Multiplexer 
des zweiten Typs mehrere Eingangsanschliisse und einen Aus- 
gangsanschluB, und der Demultiplexer einen Eingangsanschluft 
30 und mehrere Ausgangsanschlusse. 

Die Multiplexer und der Demultiplexer weisen in der Figur 1 
nicht gezeigte Steueranschlusse auf, uber welche einstellbar 
ist, welche Eingangsdaten und/oder -signale auf welche Aus- 
35 gangsanschlusse durchgeschaltet werden . Die Anzahl der 
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Steueranschliisse hangt von der erf orderlichen Anzahl der 
verschiedenen Zuordnungs-Kombinationen ab; bei 32 Eingangs- 
anschliissen und zwei Ausgangsanschliissen sind beispielsweise 
10 Steueranschliisse erf orderlich, um an beliebigen Eingangs- 
anschlussen anliegende Signale und/oder Daten auf beliebige 
Ausgangsanschlusse durchschalten zu konnen. Im Fall des Ein- 
satzes des UCB als functional unit 42 im >S<puter gemafi Figur 
3 sind die Steuersignalanschliisse vorzugsweise mit dem pro- 
grammable structure buffer 41 verbunden, so daft die in diesen 
eingeschriebenen Konf igurations-Daten im wesentlichen unmit- 
telbar zur Multiplexer-Ansteuerung verwendbar sind. Die im 
programmable structure buffer 41 gespeicherten Konfigura- 
tions-Daten umfassen vorzugsweise auch die Konf igurations- 
Daten zur Festlegung der jeweiligen Funktion der arithmeti- 
schen Einheiten AU1, AU2, der Vergleichs-Einheiten CUA, CUB, 
der Taktgenerierungs-Einheit TGU und/oder der Signalisie- 
rungs-Einheit SU. 

Durch die arithmetischen Einheiten AU1, AU2, die Vergleichs- 
Einheit des ersten Typs CUA, die Multiplexer des ersten Typs 
MUXA1, MUXA2, MUXA3, den Multiplexer des zweiten Typs MUXB, 
und den Demultiplexer DEMUX wird der UCB in die Lage ver- 
setzt, in einer Speichereinrichtung (im register file 44) ge- 
speicherte Daten auszulesen, die ausgelesenen Daten arithme- 
tisch und/oder logisch zu verarbeiten und das Ergebnis der 
Verarbeitung reprasentierende Daten in die Speichereinrich- 
tung (das register file 44) einzuschreiben . 

Wie eingangs bereits erwahnt wurde, ist der UCB darliber hin- 
aus in die Lage versetzbar, selbstandig mit externer Hardware 
zu interagieren. Die Interaktion besteht im betrachteten Bei- 
spiel darin, daft 
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- der UCB die Speichereinrichtung im Ansprechen auf bestimmte 
Ereignisse zur Obernahme von von der externen Hardware be- 
reitgestellten Daten veranlassen kann, und 

- der UCB Daten und/oder Signale an die externe Hardware aus- 
geben kann. 

Die externe Hardware besteht im betrachteten Beispiel aus 
anderen UCBs und/oder einer uber- oder nebengeordneten 
Steuereinrichtung und/oder sonstige Komponenten des den UCB 
enthaltenden Systems (beispielsweise Sensoren, A/D-Wandlern, 
D/A-Wandlern, Timern, Interrupt Controllern, zu steuernden 
Einrichtungen etc. ) . 

Die Interaktion des UCB mit externer Hardware wird im wesent- 
lichen (aber - wie aus Figur 2 ersichtlich ist - nicht aus- 
schlieBlich) durch die mindestens eine Taktgenerierungs- 
Einheit TGU und die mindestens eine Signalisierungs-Einheit 
SU bewirkt. 

Die mindestens eine Taktgenerierungs-Einheit TGU und die min- 
destens eine Signalisierungs-Einheit SU reprasentieren eine 
Schnittstelle zu der externen Hardware. Wie spater noch ge- 
nauer verstanden werden wird, kann der UCB damit eigenstandig 
(ohne Zwischenschaltung einer ubergeordneten Steuereinrich- 
tung) mit der externen Hardware interagieren . 

Der Taktgenerierungs-Einheit TGU obliegt es, basierend auf 
von innerhalb und/oder auBerhalb des UCB stammenden Signalen 
und/oder Daten ein periodisches oder nicht -per iodisches Takt- 
signal zu generieren. Die Eingangssignale sind im betrachte- 
ten Beispiel ein periodischer Master-Takt MCLK des den UCB 
enthaltenden Systems und ein Enable-Signal ENABLE einer ex- 
ternen Hardware-Komponente, mit welcher der UCB kooperieren 
soil. Grundsat zlich konnen jedoch beliebig viele und von be- 
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liebigen Quellen stammende Eingangssignale zur Taktsignal- 
erzeugung herangezogen werden. Zur Erhohung der Flexibilitat 
kann vorgesehen werden, der Taktgenerierungs-Einheit TGU 
eingangsseitig einen Multiplexer vorzuschalten; dann konnen 
die der Taktgenerierungs-Einheit zugefiihrten Eingangssignale 
applikationsspezif isch aus einer grolien Anzahl potentieller 
Eingangssignale ausgewahlt werden. Das von der Taktgenerie- 
rungs-Einheit TGU generierte Taktsignal CLK wird im betrach- 
teten Beispiel als Taktsignal fur eine im betrachteten Bei- 
spiel durch das register file 44 gebildete Speichereinrich- 
tung verwendet; das register file ist in diesem Fall dazu 
ausgelegt, das Einschreiben von Daten und/oder das Ausgeben 
von Daten im Takt des Taktsignals durchzuf uhren . Dadurch kon- 
nen 

- von externer Hardware (beispielsweise von einem A/D-Wand- 
ler) direkt Oder indirekt (beispielsweise uber die bereits 
erwahnte Load/Store-Pipeline LPL, SPL) bereitgestellte 
Daten im Takt des von der Taktgenerierungs-Einheit erzeug- 
ten Taktsignals, also zu genau definierten Zeitpunkten 
(beispielsweise auf ein das Wandlungsende des A/D-Wandlers 
signalisierendes Signal ADC_READY hin) in das register file 
4 4 ubernommen werden und/oder 

- im register file 44 gespeicherte Daten direkt oder indirekt 
(beispielsweise liber die Load/Store-Pipeline LPL, SPL) an 
externe Hardware (beispielsweise an einen externen Speicher 
wie den data cache 5 beim >S<puter gemaft Figur 3) ausgege- 
ben werden. 

Die Signalisierungs-Einheit SU besteht im betrachteten Bei- 
spiel aus einem Multiplexer des ersten Typs MUXA4 und einer 
Vergleichs-Einheit eines zweiten Typs CUB; ihr obliegt es, 
basierend auf von innerhalb und/oder aufterhalb des UCB stam- 
menden Signalen ein oder mehrere bestimmte Zustande oder 
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Ereignisse signalisierende, nachfolgend als Meldesignale be- 
zeichnete Signale zu erzeugen. Bei dem in Figur 1 gezeigten 
UCB wird nur 1 Meldesignal erzeugt. Dieses eine Meldesignal 
ist das Ausgangssignal der Vergleichs-Einheit CUB, welche die 
zwei Ausgangssignale des der Vergleichs-Einheit CUB eingangs- 
seitig vorgeschalteten Multiplexers MUXA4 vergleicht. Durch 
das Vorsehen des Multiplexers MUXA4 konnen die der Melde- 
signalerzeugung zugrundezulegenden Signale applikations- 
spezifisch aus einer grofien Anzahl von hierfiir verwendbaren 
Signalen ausgewahlt werden. Die der Meldesignalerzeugung 
zugrundelegbaren Signale umfassen im betrachteten Beispiel 
unter anderem ein Ausgangssignal der arithmetischen Einheit 
AU2 und ein Ausgangssignal des register file 44; zusatzlich 
oder alternativ konnen der Meldesignalerzeugung beliebige 
andere Signale zugrundegelegt werden. 

Das oder die Meldesignale, die durch die Signalisierungs- 
Einheit erzeugt werden, werden verwendet, urn externer Hard- 
ware bestimmte Zustande oder Ereignisse zu signalisieren . 
Damit kann beispielsweise durch ein READY-Signal das Ende der 
Ausfuhrung der durch den UCB auszuf tihrenden Operationen 
signalisiert werden. Wenn die Operationen, die der UCB aus- 
zufuhren hat, die Operationen sind, die wahrend eines Durch- 
laufs einer wiederholt zu durchlauf enden Schleife auszufuhren 
sind, so kann durch das Meldesignal auch das Ende der durch- 
zuf tihrenden Schleif endurchlauf e signalisiert werden. Die 
Vergleichs-Einheit CUB kann namlich unter anderem auch als 
Schleif enzahler verwendet werden, durcti den signalisiert 
wird, wenn die vom UCB auszuf uhrenden Operationen eine der 
durchzuf uhrenden Schleif endurchlauf e entsprechende Anzahl von 
Malen ausgefuhrt wurden. Die Meldesignale konnen unter ande- 
rem auch als Interrupt Requests verwendet werden. 

Die Vergleichs-Einheit CUB entspricht ubrigens weitestgehend 
der Vergleichs-Einheit des ersten Typs CUA; unterschiedlich 
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ist im wesentlichen "nur", daft die Standard-Einstellung des 
Pegels des Ausgangssignals FALSE sein kann, und daft die 
Standard-Einstellung des Pegels des Ausgangssignals vorzugs- 
weise applikationsspezif isch einstellbar ist. 

5 

Der in Figur 1 gezeigte und unter Bezugnahme darauf beschrie- 
bene UCB ist nur zur Erlauterung des grundlegenden Aufbaus 
gedacht. In der Praxis werden die arithmetische Einheiten, 
die Vergleichs-Einheiten, die Multiplexer, die Demultiplexer, 

10 und gegebenenf alls auch die Taktgenerierungs-Einheit und die 
Signalisierungs-Einheit in einer deutlich grofteren Anzahl 
^^ m ,J vorgesehen werden als es beim Beispiel gemaft Figur 1 der Fall 
ist. Der UCB ist vorzugsweise so dimensioniert , daft normaler- 
weise samtliche Operationen, die von einem spater noch naher 

15 beschriebenen, sogenannten Hyperblock zu bewirken sind, auf 
ein Mai in ihn einprogrammierbar sind. 

Die im UCB vorgesehenen Daten- und/oder Signalpfade konnen 
durch einzelne Leitungen oder durch Busse gebildet werden, 
20 wobei es sich als vorteilhaft erweisen kann, wenn in den ein- 
zelnen Komponenten des UCB oder im Bus-System konf igurierbar 
ist, wie viele und/oder welche Busleitungen zu berucksichti- 
/ - gen sind. 

25 Ein UCB der vorstehend beschriebenen Art erweist sich gegen- 
liber herkommlichen konf igurierbaren Hardware-Blocken (feld- 
programmierbaren Logiken) in mehrfacher Hinsicht als vor- 
teilhaft. 

30 Ein erster Vorteil besteht darin, daft die datenver knupf enden 
Einheiten des UCB zur Ausfuhrung komplexerer Operationen in 
der Lage sind. D.h., es findet eine zumindest partielle Ab- 
kehr von auf DNFs (dis j unktiven Normalf ormen) basierenden 
oder tabellenorientierten logischen Verknupf ungen statt; pro 
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arithmetischer Einheit (AU) sind eine oder sogar mehrere 
arithmetisch-logische Ver knupf ungen realisierbar . 

Die in den UCBs (deren arithmetischen Einheiten) ausfuhrbaren 
5 Operationen sind zudem umf angreicher (grober geblockt) als es 
etwa bei FPGAs (field programmable gate arrays) der Fall ist. 
Die durch die einzelnen arithmetischen Einheiten ausfuhrbaren 
Operationen lassen sich dadurch schneller, einfacher und si- 
cherer in Ubereinstimmung mit den Aktionen bringen, die durch 
10 Instruktionen oder Algorithmen fur programmgesteuerte Einhei- 
ten zu bewirken sind, wodurch sich in programmgesteuerten 
> Einheiten auszuf iihrende Programme oder Programmteile mit 

minimalem Aufwand in Konf igurations-Daten umsetzen lassen, 
durch welche der UCB derart konfiguriert wird, daft dessen 
15 Betrieb die Vornahme der durch die Abarbeitung des betref fen- 
den Programms oder Programmteils zu bewirkenden Aktionen zur 
Folge hat. 

Wie eingangs bereits erwahnt wurde, zeichnen sich die UCBs 
20 ferner dadurch aus, daft sie selbstandig mit externer Hardware 
kooperieren konnen, wobei es sich insbesondere bei Verbindun- 
gen zu rechnenden Einheiten als vorteilhaft erweisen kann, 
wenn die Kopplung zur externen Hardware zumindest teilweise 
uber die sogenannten Load/Store-Pipelines erfolgt. 

25 

Vorteilhaft ist ferner, daft das den UCB synchronisierende 
Element, namlich die Speichereinrichtung (im betrachteten 
Beispiel das register file 44) Verbindungen zur externen 
Hardware aufweist. 

30 

Hardware-Blocke nach Art der Figur 1 konnen und werden vor- 
zugsweise basierend auf Befehlen oder Bef ehlsf olgen konfigu- 
riert. Setzt man Befehle oder Bef ehlsf olgen in entsprechende 
Hardware-Block-St rukturen um, so ist der so konf igurierte 
35 Hardware-Block als Ablauf einheit fur sequentielle Befehls- 
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folgen nutzbar. Diese Form der Hardware-Block-Konf igurierung 
wird nachfolgend auch als struktur-prozedurale Programmierung 
bezeichnet . 

5 Ausgangspunkt fur die struktur-prozedurale Programmierung 

kann ein in einer Hochsprache wie beispielsweise C, C+ + etc. 
geschriebenes Programm sein. Dieses Programm wird durch einen 
Compiler iibersetzt, und der dabei erhaltene Code wird (vor- 
zugsweise hyperblock-weise) in Strukturinf ormationen umge- 
10 setzt, basierend auf welcher der zu konf igurierende Hardware- 
Block konf igurierbar ist. Was unter einem Hyperblock zu ver- 
stehen ist, wird spater noch genauer beschrieben werden. 

Ausgangspunkt fur die struktur-prozedurale Programmierung 
15 kann selbstverstandlich auch ein in Assembler geschriebenes 
oder sonstiges Programm sein. Die Art und Weise der Pro- 
grammierung (funktional, imperativ, ob j ekt-orientiert , . . . ) 
ist ebenfalls keinen Einschrankungen unterworfen. 

20 Es erweist sich als vorteilhaft, wenn der in die Struktur- 
information umzusetzende Code, also die durch den Compiler 
oder auf andere Art und Weise erzeugten Maschinenbef ehle im 
we sent lichen ausschlieftlich f iinf Maschinenbef ehl-Typen, 
namlich unkonditionierte Befehle, konditionierte Befehle, 
25 Predicate-Bef ehle, Loopxx-Bef ehle, und Intxx-Bef ehle umfas- 

sen. Dann lassen sich in der Regel besonders lange (besonders 
viele Befehle enthaltende) Bef ehls-Blocke mit nur einem Ein- 
trittspunkt und nur einem Austrittspunkt bilden. Die Gene- 
rierbarkeit von moglichst langen Bef ehls-Blocken mit nur 
30 einem Eintrittspunkt und nur einem Austrittspunkt ist sehr 
bedeutsam, weil sich Befehle, die ein- und dem selben 
Bef ehls-Block angehoren, und zwar nur solche Befehle, als 
eine Einheit (als eine sich aus mehreren Befehlen zusammen- 
setzende Makroinstruktion) behandeln lassen, die in eine 
35 gemeinsame Hardware-Block-Struktur umgesetzt und auf ein Mai 
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ausgefuhrt werden kann. Legt man der Konf igurierung eines 
Hardware-Blocks jeweils genau eine solche Einheit zugrunde 
(und ist der Hardware-Block grofi genug, urn so konfiguriert 
werden zu konnen) , so lailt sich die Anzahl der zur Abarbei- 
5 tung eines Progranuns erf orderlichen Umstrukturierungen bzw. 
Umkonf igurierungen des Hardware-Blocks auf ein Minimum redu- 
zieren. Die Bef ehls-Blocke, deren Generierung derzeit favori- 
siert wird, und deren Bildung durch die vorstehend genannten 
Bef ehlsgruppen auch moglich ist, sind die vorstehend bereits 
10 erwahnten Hyperblocke. 

1 Hyperblocke zeichnen sich insbesondere dadurch aus, daft be- 
dingte Sprungbef ehle unter Anwendung der nachfolgend noch 
naher beschriebenen sogenannten if -Konversion eliminiert wer- 

15 den. 

Bezuglich weiterer Einzelheiten zu den Hyperblocken, anderen 
Bef ehls-Blocken und damit in Zusammenhang stehenden Themen 
wird auf 

20 

- Wen-Mei W. Hwu et al. : "Compiler Technology for Future 
Microprocessors", Invited Paper in Proceedings of the IEEE, 
Vol. 83 (12), Dezember 1995, Special Issue on Micro- 
processors, Seiten 1625 bis 1640, 

25 

- Henk Neefs, Jan van Campenhout : "A Microarchitecture for a 
Fixed Length Block Structured Instruction Set Archi- 
tecture", Proceedings of the Eighth IASTED International 
Conference on Parallel and Distributed Computing and 

30 Systems, Seiten 38 bis 42, IASTED/ACTA Press, 1996, und 

- Richard H. Littin, J. A. David McWha, Murray W. Pearson, 
John G. Cleary: "Block Based Execution and Task Level 
Parallelism", in: John Morris (Ed.), "Computer Architecture 

35 98", Proceedings of the 3 rd Australasian Computer Archi- 
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tecture Conference, ACAC'98, Perth, 2-3 February 1998 , 
Australian Computer Science Communications, Vol. 20, No. 4, 
Seiten 57 bis 66, Springer, Singapore, 

5 verwiesen. 

Wie vorstehend bereits angedeutet wurde, ist ein Hardware- 
Block vorzugsweise so dimensioniert , daB dessen Konfigurie- 
rung hyperblock-weise erfolgen kann, also nach Moglichkeit 
10 immer ganze Hyperblocke in entsprechende Hardware-Block- 
Strukturen umgesetzt werden konnen. 

Die vorstehend erwahnten unkonditionierten Befehle sind Be- 
fehle zur bedingungslosen Bearbeitung von Daten einschlieft- 
15 lich der Kopie von Daten von einem Speicherbereich in einen 
anderen (von einem Register in ein anderes) . Diese Befehle 
werden im folgenden als normale Befehle bezeichnet. Sie um- 
fassen arithmetische und logische Verknupf ungen zwischen 
Daten zu neuen Werten und die sogenannten Move-Befehle zur 
20 Kopie von Registerinhalten . Das allgemeine Format dieser Be- 
fehle lautet: <Mnemonic> <Ziel-Register>, <Quellen-Register 
1>, <Quellen-Register 2>. Zur Durchfuhrung eines solchen 
Befehls wird eine arithmetische Einheit des Hardware-Blocks 
benotigt . 



Die konditionierten Befehle sind Befehle zur Bearbeitung von 
Daten bei Vorliegen einer bestimmten Bedingung (Kondition) . 
Die durch diese Befehle auszuf uhrenden Aktionen bzw. Opera- 
tionen entsprechen den durch die normalen Befehle ausfuhr- 

30 baren Aktionen bzw. Operationen, wobei die Ausfiihrung der 

betreffenden Aktionen jedoch von einer vorbestimmten Bedin- 
gung abhangt . Ist die Bedingung erfiillt, wird die durch den 
Befehl spezif izierte Aktion ausgefiihrt, anderenfalls wird 
nichts ausgefiihrt (der betreffende Befehl wirkt dann wie ein 

35 NOP-Befehl) . Diese Befehle werden im folgenden als bedingte 
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Befehle bezeichnet. Das allgemeine Format dieser Befehle 
lautet: <Mnemonic>p <Ziel-Register>, <Quellen-Register 1>, 
<Quellen-Register 2> <p-Flag>, wobei durch das "p" am Ende 
des Mnemonic die Abhangigkeit der Befehlsausf uhrung von einer 
Bedingung signalisiert wird, und wobei die Bedingung durch 
einen bestimmten Zustand eines bestimmten Flags (des "p- 
Flag" ) definiert wird. Zur Durchf uhrung der durch einen sol- 
chen Befehl spezif izierten Aktion wird eine arithmetische 
Einheit des Hardware-Blocks benotigt; zur Oberpriifung der 
Bedingung wird eine Vergleichs-Einheit benotigt, deren Aus- 
gang mit dem Steuereingang der arithmetischen Einheit verbun- 
den ist. 

Die Predicate-Bef ehle sind Befehle zur Festlegung des Zustan- 
des des in den bedingten Befehlen verwendeten Bedingungs- 
Flags (des p-Flags). Die Festlegung erfolgt dabei wahrend des 
Programmablaufs basierend auf einem Vergleich von zwei Daten. 
Diese Befehle werden im folgenden als pxx-Befehle bezeichnet. 
Das allgemeine Format dieser Befehle lautet: pxx <Quellen- 
Register l> f <Quellen-Register 2>, <p-Flag>, wobei xx die 
durchzuf uhrende Vergleichsoperation spezifiziert und durch gt 
(grofier als), ge (grofier oder gleich) , eq (gleich), ne 
(ungleich) , le (kleiner oder gleich) oder It (kleiner als) zu 
ersetzen ist. Die pxx-Befehle sind mit den ublichen Branch- 
Befehlen vergleichbar und dienen zum Ersatz derselben durch 
die Anwendung der sogenannten if-Konversion (siehe hierzu den 
vorstehend bereits erwahnten Aufsatz von Wen-Mei W. Hwu et 
al.). 

Die Loopxx-Bef ehle sind zur Schleif enwiederholung dienende 
Befehle am Ende eines Hyperblocks. Sie veranlassen einen 
Rucksprung an den Anfang des betreffenden Hyperblocks, falls 
eine im Befehl spezif i zierte Bedingung erfullt ist; sie ver- 
anlassen eine durch die Signalisierungs-Einheit SU vorzuneh- 
mende Generierung eines READY-Signals, wenn die Bedingung 



GR 98 P 8107( 




21 

nicht mehr erfullt ist. Die Bedingung ist durch ein bestimm- 
tes Ergebnis einer Vergleichsoperation definiert. Das all- 
gemeine Format dieser Befehle lautet: loopxx <Quellen- 
Register 1>, <Quellen-Register 2>, wobei xx die durchzu- 
5 fiihrende Vergleichsoperation spezif iziert . 

Die Intxx-Bef ehle sind Befehle zur Erzeugung von an die ex- 
terne Hardware auszugebenden Signalen. Sie stellen eine Ver- 
allgemeinerung der Loopxx-Bef ehle dar: damit konnen aus be- 

10 liebigen Anlassen beliebigen Bedeutungsinhalt aufweisende 

Signale an beliebige externe Komponenten des den UCB enthal- 
tenden Systems ausgegeben werden. Das allgemeine Format die- 
ser Befehle lautet: intxx <Quellen-Register 1>, <Quellen- 
Register 2>, <int_Signal>, wobei xx die durchzuf iihrende 

15 Vergleichsoperation spezif iziert , und wobei "int_Signal" das 
(durch die Signalisierungs-Einheit SU) zu erzeugende und aus- 
zugebende Meldesignal spezif iziert . 

Daft der UCB die Operationen, die durch die vorstehend auf- 
20 gezahlten und erlauterten Befehlstypen spezifiziert sind, 
ausfiihren kann, macht diesen zu einer aufierst vielfaltig 
einsetzbaren Komponente. Damit sind viele Programme oder 
Programmteile vollstandig durch den UCB ausfuhrbar. Der UCB 
kann als mehr oder weniger vollwertiger Ersatz von programm- 
25 gesteuerten Einheiten verwendet werden, oder - wenn er Be- 
standteil einer programmgesteuerten Einheit ist oder mit 
einer solchen kooperiert - deren Leistungsf ahigkeit erheblich 
steigern . 

30 Nachfolgend wird der Vollstandigkeit kurz erlautert, wie die 
Umsetzung der Befehle in eine entsprechende UCB-Struktur (die 
Selbstkonf igurierung des UCB aus einem sequent iellen Instruk- 
tionsstrom) erfolgen kann. Da hier nur das grundlegende Prin- 
zip der Umsetzung erlautert werden soil, beschranken sich die 

35 folgenden Ausfiihrungen auf die Umsetzung der normalen, be- 
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dingten, und pxx-Befehle. Die anderen Befehle, genauer gesagt 
die Loopxx- und Intxx-Bef ehle erfordern unter Umstanden eine 
Sonderbehandlung, die jedoch bei Kenntnis des nachfolgend be- 
schriebenen Vorgehensweise keine Schwierigkeit bereitet. 

5 

Der UCB, genauer gesagt dessen Teileinheiten (arithmetische 
Einheiten, Vergleichs-Einheiten, Multiplexer, Demultiplexer, 
. . . ) und die Verbindungen zwischen den Teileinheiten werden 
im betrachteten Beispiel durch die gewunschte Konf iguration 

10 reprasentierende Konf igurations-Daten (Konf igurations-Bits ) 
konf iguriert . Dementsprechend ist es die Aufgabe des nach- 
folgend beschriebenen Umsetzungsverf ahrens, ( vorzugsweise 
definiert vorbesetzte) Konf igurations-Bits bzw. einen diese 
enthaltenden Bitstrom basierend auf den der UCB-Konf iguration 

15 zugrundezulegenden Befehlen oder Bef ehlsf olgen zu generieren 
bzw . modif izieren . 



Insbesondere wenn die Teileinheiten des UCB konf igurierbar 
sind, werden diesen (physikalischen) Teileinheiten logische 

20 bzw. virtuelle Einheiten zugeordnet, wobei die virtuellen 
Einheiten die verschiedenen Funktionen der physikalischen 
Teileinheiten angeben. Der physikalischen Teileinheit "erste 
arithmetische Einheit AU1" konnen - sofern diese konfigurier- 
bar ist - beispielsweise die virtuellen Einheiten Addierer, 

25 Subtrahierer etc. zugeordnet sein. Eine virtuelle Einheit ist 
genau einer physikalischen Teileinheit zugeordnet ist, aber 
einer physikalischen Teileinheit konnen mehrere virtuelle 
Einheiten zugeordnet sein. Samtliche virtuellen Einheiten 
werden vorzugsweise in einer Tabelle oder Liste verwaltet. 

30 Die jeweiligen Eintrage enthalten neben Inf ormationen zu den 
virtuellen Einheiten selbst auch Information daruber, welcher 
physikalischen Teileinheit die jeweiligen virtuellen Einhei- 
ten zugeordnet sind, iiber welche Konf igurations-Bits und wie 
diese physikalische Teileinheit gegebenenf alls konfiguriert 
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werden mufi, um ihr die durch die virtuelle Einheit reprasen- 
tierte Funktion zu verleihen. 

Die Umsetzung einer Instruktion in eine UCB-Struktur ierungs- 
5 inf ormationen erfolgt im wesentlichen in drei Schritten. 

Im ersten Schritt wird zunachst ermittelt, welcher Typ von 
virtueller Einheit (Addierer, Subtrahierer , Multiplizierer 
. . . ) zur Ausfuhrung der umzuset zenden Instruktion benotigt 

10 wird, und ob eine solche virtuelle Einheit noch verfugbar 
ist. 1st noch eine virtuelle Einheit des benotigten Typs 

' frei, so wird diese oder eine von diesen zur Ausfuhrung der 
betreffenden Instruktion ausgewahlt. Sodann erfolgen die Kon 
figuration oder deren Vorbereitung und eine Reservierung der 

15 der ausgewahlten virtuellen Einheit zugeordneten physikali- 
schen Teileinheit. Zur Konf iguration werden einfach die der 
betreffenden physikalischen Teileinheit zugeordneten Konfigu 
rations-Bits gesetzt oder zuruckgesetzt ; dies bereitet keine 
Schwierigkeiten, denn die Inf ormationen, welcher physikali- 

20 schen Teileinheit die ausgewahlte virtuelle Einheit zugeord- 
net ist, liber welche Konf igurations-Bits und wie diese physi 
kalische Teileinheit gegebenenf alls zu konf igurieren ist, 




werden ja zusammen mit der virtuellen Einheit verwaltet. Die 
Reservierung der der ausgewahlten virtuellen Einheit zugeord 



25 neten physikalischen Teileinheit ist notwendig, um zu verhin 
dern, daft die betreffende physikalische Teileinheit mehrfach 
verwendet werden kann. Im betrachteten Beispiel wird dies 
dadurch bewerkstelligt , daft nach jeder Vergabe einer physika 
lischen Teileinheit fur einen bestimmten Zweck samtliche vir 

30 tuellen Einheiten, die der betreffenden physikalischen Teil- 
einheit en zugeordnet werden, gesperrt werden . 

Bei pxx-Befehlen kann es je nach dem Aufbau des UCB erforder 
lich sein, abhangig vom p-Flag eine ganz Vergleichs-Einheit 
35 auszuwahlen . 
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Bei bedingten Befehlen wirkt sich das p-Flag nur dann auf di 
Auswahl der virtuellen/physikalischen Einheit(en) aus, wenn 
bestimmte Instruktionen nur mit bestimmten Flags moglich 
5 sind, also keine vollstandige Orthogonalitat in dem Teil- 
befehlssatz fur bedingte Befehle vorhanden ist. 

Im zweiten Schritt der UCB-Konf igurierung werden die den 
ausgewahlten physikalischen Teileinheiten vor- und/oder nach 

10 geschalteten Multiplexer konf iguriert , urn die Daten und/oder 
Signalquellen und die Daten- und/oder Signalziele entspre- 
\j chend den Festlegungen in den umzusetzenden Instruktionen 

einzustellen . Die Multiplexer und das Format der umzusetzen- 
den Instruktionen sind im Idealfall so aneinander angepafit, 

15 daft die die Daten- und/oder Signalquellen und die die Daten- 
und/oder Signalziele festlegenden Teile der Instruktionen un 
verandert als die die Multiplexer konf igurierenden Konfigura 
tions-Bits ubernommen werden konnen. Ist dies - aus welchem 
Grund auch immer - nicht moglich oder gewunscht, so konnen 

20 die die Multiplexer konf igurierenden Konf igurat ions-Bits bei 
spielsweise einer Tabelle entnommen werden, in welcher die 
Zuordnung zwischen den die Daten- und/oder Signalquellen und 
die Daten- und/oder Signalziele festlegenden Teilen der In- 
■y struktionen und den die Multiplexer konf igurierenden Konfigu 

25 rations-Bits gespeichert ist. Die Konf igurierung, die erf or- 
derlich ist, um eine Verbindung zu einer bestimmten Daten- 
und/oder Signalquelle und/oder zu einem bestimmten Daten- 
und/oder Signalziel herzustellen, ist vorzugsweise fur alle 
Multiplexer gleich . 

30 

Eine gesonderte Behandlung ist notwendig, wenn die der auszu 
fuhrenden Operation zugrundezulegenden Daten zumindest teil- 
weise aus einer im Instruktions-Code enthaltenen Konstanten 
bestehen. Dann muft 
35 - ein freies (Konstanten-) Register gesucht werden, 
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- dieses Register als Daten- und/oder Signalquelle verwendet 
werden, und 

- die im Instruktions-Code enthaltene Konstante vor der In- 
betriebnahme des UCB in das ausgewahlte Register einge- 

5 schrieben werden . 

Es kann vorgesehen werden, vorab zu uberpriifen, ob die be- 
treffende Konstante schon in einem (Konstanten-) Register 
gespeichert ist. Ergibt sich dabei, dafi bereits ein die Kon- 

10 stante enthaltendes (Konstanten-) Register existiert, so kann 
dieses schon existierende (Konstanten-) Register als Daten- 

1 und/oder Signalquelle verwendet werden. 

Zu beachten ist ferner, dafi die umzuset zenden Instrukt ionen 
15 unterschiedlich viele Daten- und/oder Signalquellen und 
Daten- und/oder Signalziele aufweisen. 

Als Daten- und/oder Signalziel verwendete Register werden 
ubrigens als belegt markiert, da innerhalb eines Hyperblocks 
20 keine Zweitbelegung zulassig ist und durch ein sogenanntes 
(Runtime) Register Renaming, einer aus superskalaren Archi- 
tekturen bekannten Technologie, verhindert werden muli . 

Nach diesem ( fur a lie Bef ehle gemeinsamen) zweiten Schritt 
25 werden fur einzelne Befehlstypen spezielle Teilschritte ein- 
gef ugt , die sich aus den j eweiligen Be sonde rhe it en ergeben . 

Unter anderem muli bei bedingten Befehlen die das Vorliegen 
der Bedingung uberpriif ende Vergleichs-Einheit ermittelt wer- 
30 den und deren Ausgangssignal iiber den zugehorigen Demulti- 
plexer auf die die Operation aus f uhr ende arithmetische Ein- 
he it geschaltet werden . Ferner ist zu berucksichtigen, wel- 
cher Art die Bedingung ist. 
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Bei bedingten Move-Bef ehlen ist zusatzlich dafur Sorge zu 
tragen, dafi der Inhalt des Zielregisters bei Nicht-Ausf uhrung 
des Befehls nicht verandert wird. 

5 Nach dem zweiten Schritt der UCB-Konf igurierung konnte diese 
beendet und der UCB gestartet werden. Dies geschieht vorzugs- 
weise jedoch erst nach der Ausfuhrung des nachfolgend be- 
schriebenen dritten Schrittes. 

10 In diesem dritten Schritt der UCB-Konf igurierung wird ein so- 
genanntes data forwarding realisiert. Dabei werden als Daten- 
und/oder Signalquellen nicht stur die in den Instruktionen 
angegebenen Daten- und/oder Signalquellen verwendet, sondern 
nach Moglichkeit die physikalische Teileinheit, die die be- 

15 treffende Daten- und/oder Signalquelle innerhalb des jeweili- 
gen Hyperblocks zuvor zu beschreiben hatte. Dies erweist sich 
in zweifacher Hinsicht als vorteilhaft: einerseits, weil 
eventuell weniger Register benotigt werden (wenn die in der 
Instruktion angegebene Daten- und/oder Signalquelle nicht als 

20 solche verwendet wird, muft sie auch nicht beschrieben werden 
und kann gegebenenf alls ganz weggelassen werden) , und ande- 
rerseits, weil die benotigten Daten bei Abholung von der 
diese erzeugenden Teileinheit (beispielsweise einer arith- 
metischen Einheit) friiher verfugbar sind als wenn sie zuerst 

25 in ein Register geschrieben und von dort abgeholt werden mus- 
sen. Das data forwarding kann bei alien Bef ehlen zur Anwen- 
dung kommen und erweist sich im Durchschnitt als enormer Vor- 
teil. 

30 Abschliefiend soil ein praktisches Beispiel zum Einsatz des 
UCB beschrieben werden . 

Das Beispiel betrifft eine Analog/Digital-Wandlung von Daten. 
Genauer gesagt soil 



35 
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- ein A/D-Wandler mit einer Wandlungsbreite von 8 Bit von 
einem Timer gestartet werden, 

das Ergebnis der A/D-Wandlung zusammen mit einer 12-Bit- 
5 Zahlmarke gespeichert werden, 

das Ergebnis der A/D-Wandlung auf das Ober- und Unter- 
schreiten bestimmter Grenzwerte iiberwacht werden, wobei 
bei einem Uber- oder Unterschreiten der Grenzwerte in eine 
10 bestimmte Routine zu verzweigen ist, 

und der Vorgang nach 2048 Messungen abgebrochen werden. 

Eine derartige Anwendung erfordert bei einer reinen Software- 
15 losung einen relativ hohen Aufwand. Da ein typischer A/D- 
Wandler (beispielsweise ein in einem Microcontroller inte- 
grierter A/D-Wandler) in der Regel nicht spontan das Ergebnis 
liefert, also als sogenannter Flash-Wandler arbeitet und eine 
Wandlungszeit im Bereich einiger Mikrosekunden besitzt, muli 
20 bei exakter Ausfiihrung der Anwendungsspezif ikation einer der 
folgenden Wege beschritten werden: 

1) Der Timer lost einen Interrupt aus. Die Interrupt-Service- 
routine startet die A/D-Wandlung und wird dann beendet . 
25 Der A/D-Wandler lost bei Beendigung der Wandlung ebenfalls 

einen Interrupt aus. Durch die daraufhin ausgefuhrte 
Interrupt-Serviceroutine wird das A/D-Wandlungsergebnis 
ausgelesen und verarbeitet. 

30 2) Der Timer lost einen Interrupt aus. In der daraufhin aus- 
gefuhrten Interrupt-Serviceroutine wird die A/D-Wandlung 
gestartet, auf das Wandlungsende gewartet, und schliefilich 
(nach dem Wandlungsende) das A/D-Wandlungsergebnis ausge- 
lesen und verarbeitet. 



35 
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Wenn die Wandlungszeiten kiirzer als die Interrupt-Latenz- 
zeiten sind, ist der zweiten Variante der Vorzug zu geben. 
Ansonsten ware die erste Variante zu bevorzugen. Am gunstig- 
sten ist jedoch - jedenfalls bei Ausfuhrung in einem "nor- 
5 malen" Mikroprozessor oder Mikrocontroller - im allgemeinen 
die folgende dritte Variante: 

3) Der Timer lost einen Interrupt aus. In der daraufhin aus- 
geftihrten Interrupt-Serviceroutine wird das letzte A/D- 
10 Wandlungsergebnis ausgelesen, die nachste A/D-Wandlung 

gestartet, und das ausgelesene A/D-Wandlungsergebnis aus- 
gewertet. 

Dann erfolgt das Lesen und Auswerten des A/D-Wandlungs- 
15 ergebnis allerdings in der Regel spater als es eigentlich 
moglich ware. 

Mochte man das Auslesen, das Auswerten und das Speichern der 
A/D-Wandlungsergebnisse durch einen UCB erledigen lassen, so 

20 wiirde man diesen vorzugsweise entsprechend dem folgenden C- 
Programm konf igurieren . Wie spater noch besser verstanden 
werden wird, kann dadurch mit minimalem Aufwand und mit mini- 
maler Belastung des den UCB enthaltenden Systems ein sofort 
nach dem A/D-Wandlungsende einsetzendes Auslesen, Auswerten 

25 und Speichern des A/D-Wandlungsergebnisses durchgefuhrt wer- 
den, Im folgenden C-Programm wird ein neues Schlusselwort 
"hardware_thread" verwendet. Uber dieses Schlusselwort, das 
selbstverstandlich auch beliebig anders lauten kann, soil dem 
das C-Programm iiberset zenden Compiler signalisiert werden, 

30 dafi er das betreffende Programm oder den betreffenden Pro- 
grammabschnitt so kompilieren soil, dali der erzeugte Code 
moglichst effizient in einem UCB ausfuhrbar ist. Die Ver- 
wendung eines solchen Schliisselwortes ist jedoch nicht zwin- 
gend erf orderlich . Es konnte auch vorgesehen werden, dali der 

35 Compiler die zu kompilierenden Programme von Haus aus so 



GR 98 P 8107 



29 

kompiliert, daft sie in UCBs zur Ausfuhrung gebracht werden 
konnen. 



int *p_adc, adc__value, upper_limit, lower_limit, adc_ready; 
5 int adc_array (4096) ; 

void hardware_thread readAD ( ) 
{ 

int x = 0; 
10 while ( x < 4096 ) 

{ 

if ( adc_ready == 1 ) 
{ 

// Zugriff auf A/D-Wandler 
15 adc_value = *p_adc; 

// Aufruf der Routine out_of_range bei 
// Gr en zwert liber schreitung 
if( adc_value > upper__limit II 
20 adc_value < lower_limit ) out_of_range ( ) ; 

// Speichern der Index-Information 
adc_array [x++] = x; 

25 // Speichern des Wandlungsergebnisses 

adc_array [x++] = adc_value; 



30 



Dieser Source -Code kann bei Verwendung der vorstehend genann- 
ten Bef ehlstypen in f olgenden Assembler-Code uberset zt wer- 
den : 
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mov rl, p_adc 

mov r4, 0 

mov r5, 1 

mov r6, adc_array 

Id r2, upper_limit 

Id r3, lower limit 



Adresse des A/D-Wandlers -> rl 
Variable x -> r4 
x+1 -> r5 

Speicherf eldadresse -> r6 
oberer Grenzwert -> r2 
unterer Grenzwert -> r3 



10 



15 



20 



25 



30 



LO: Id rO, (rl) 

intgt rO, r2, il 

intlt rO, r3, i2 

st (r6+r4) , r4 
st (r6+r5), rO 
add r4, r4, 2 
add r5, r5, 2 
looplt r4, 4096 



A/D-Wandlungsergebnis wird geladen 
Meldesignal INT1 (Interrupt 
Request 1) erzeugen, wenn rO > r2 
Meldesignal INT2 (Interrupt 
Request 2) erzeugen, wenn rO < r3 
Zahlmarken-Speicherung 
A/D-Wandlungsergebnis -> rO 
Aktualisierung von x 
Aktualisierung von x+1 
Wiederholung ab L0, 
wenn r4 < 4096 



35 



Dabei betreffen die ersten 6 Instruktionen die Initialisie- 
rung der Register, und die nachf olgenden (ab dem Label. L0 
kommenden) Instruktionen die Ausfuhrung der durch das vor- 
stehende C-Programm zu bewirkenden Aktionen. 

Zwar fehlt im Assembler-Code die Bedingung, daft die Schleife 
nur bei Vorliegen des ADC_READY-Signals durchlaufen werden 
darf, doch kommt man bei der Umsetzung des Assemblerprogramms 
in eine UCB-Struktur und Ausfuhrung durch den UCB dennoch zum 
gleichen Ergebnis wie bei "normaler" Ubersetzung des C-Pro- 
gramms und Ausfuhrung desselben in einem her kommlichen Mikro- 
prozessor oder Mikrocontroller . Die im Assembler-Code feh- 
lende Bedingung stellt namlich quasi eine Triggerung dar, die 
auch durch das der Taktgenerierungs-Einheit TGU des UCB zu- 
gefuhrte Enable-Signal ENABLE bewer kstelligbar ist. 



GR 98 P 8107i 



31 

Setzt man den Assembler-Code in eine UCB-Struktur urn, durch 
welche die zu bewirkenden Aktionen vorgenommen werden, so 
gelangt man zu der in Figur 2 gezeigten UCB-Struktur. 

Der in der Figur 2 gezeigte UCB umfafit vier als Addierer kon- 
figurierte arithmetische Einheiten AU1, AU2, AU3, AU4 , eine 
Taktgenerierungs-Einheit TGU, und eine drei Vergleichs- 
Einheiten CUB1, CUB2, CUB3 umfassende Signalisierungs-Einheit 
SU. Die Struktur des UCB basiert erkennbar auf der in der 
Figur 1 veranschaulichten allgemeinen Struktur von UCBs; es 
fand lediglich eine Anpassung an den konkreten Anwendungsf all 
statt. Die Verschaltung der Teileinheiten des UCB sowie deren 
Ein- und Ausgangssignale sind der Figur 2 selbst entnehmbar 
und bediirfen keiner weiteren Erlauterung. Es ist ohne weite- 
res nachvollziehbar , daft ein so konf igurierter UCB genau das 
tut, was durch den vorstehenden Assembler-Code (das vorste- 
hende C-Programm) definiert ist. 

Es durfte einleuchten, daft der so konf igurierte UCB die zu 
bewaltigende Aufgabe vollig selbstandig (ohne Belastung einer 
uber- oder nebengeordneten Steuereinrichtung) und erheblich 
schneller als ein herkommlicher Mikroprozessor oder Mikro- 
controller ausfuhren kann. 

Der beschriebene Hardware-Block (UCB) erweist sich nach alle- 
dem in mehrfacher Hinsicht als vorteilhaft: er ist leistungs- 
fahiger und flexibler und universeller einsetzbar als es bei 
herkommlichen Hardware-Blocken der betrachteten Art der Fall 
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Patentanspriiche 

1. Konf igurierbarer Hardware-Block, der dazu ausgelegt ist 
abhangig von seiner Konf iguration in einer Speichereinrich- 
tung (44) gespeicherte Daten auszulesen, die ausgelesenen 
Daten arithmetisch und/oder logisch zu verarbeiten, und das 
Ergebnis der Verarbeitung reprasentierende Daten in die 
Speichereinrichtung einzuschreiben, 

dadurch gekennzeichnet, 

daft der Hardware-Block in die Lage versetzbar ist, mit exter 
ner Hardware zu interagieren . 

2. Konf igurierbarer Hardware-Block nach Anspruch 1, 
dadurch gekennzeichnet, 

daft die Interaktion mit der externen Hardware darin besteht, 
die Speichereinrichtung (44) im Ansprechen auf bestimmte 
Ereignisse zur Obernahme von von der externen Hardware 
bereitgestellten Daten zu veranlassen. 

3. Konf igurierbarer Hardware-Block nach Anspruch 1 oder 2, 
dadurch gekennzeichnet, 

daft die Interaktion mit der externen Hardware darin besteht, 
Daten und/oder Signale an die externe Hardware auszugeben. 

4. Konf igurierbarer Hardware-Block nach einem der vorher- 
gehenden Anspriiche, 

dadurch gekennzeichnet, 

daft die externe Hardware aus weiteren konf igurierbaren Hard- 
ware-Blocken und/oder einer uber- oder nebengeordneten 
Steuereinrichtung und/oder sonstigen Einheiten des den kon- 
f igurierbaren Hardware-Block enthaltenden Systems besteht. 

5. Konf igurierbarer Hardware-Block nach Anspruch 3 oder 4, 
dadurch gekennzeichnet, 
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dafl die an die externe Hardware ausgegebenen Daten und/oder 
Signale bestimmte Zustande oder Ereignisse signalisierende 
Daten und/oder Signale sind- 

6. Konf igurierbarer Hardware-Block nach einem der vorher- 
gehenden Anspriiche, 

dadurch gekennzeichnet, 

dali eine Taktgenerierungs-Einheit (TGU) zur Generierung von 
Taktsignalen (CLK) fur die Speichereinrichtung (44) vorgese- 
hen ist. 

7. Konf igurierbarer Hardware-Block nach Anspruch 6, 
dadurch gekennzeichnet, 

dafl die Taktgenerierungs-Einheit (TGU) die Taktsignale (CLK) 
in Abhangigkeit von einem oder mehreren periodischen oder 
nicht periodischen Signalen (MCLK, ENABLE; MCLK, ADC_READ) 
erzeugt, die zumindest teilweise von der externen Hardware 
stammen . 

8. Konf igurierbarer Hardware-Block nach einem der vorher- 
gehenden Anspriiche, 

dadurch gekennzeichnet, 
dali eine Signalisierungs-Einheit (SU) zur Erzeugung von 
Meldesignalen (READY, INT1, INT2) fur die externe Hardware 
vorgesehen ist. 

9. Konf igurierbarer Hardware-Block nach Anspruch 8, 
dadurch gekennzeichnet, 

dafl durch die Meldesignale (READY, INT1, INT2) das Auftreten 
vorbestimmter Zustande und/oder Ereignisse im konfigurier- 
baren Hardware-Block signalisiert wird. 

10. Konf igurierbarer Hardware-Block nach Anspruch 8 oder 9, 
dadurch gekennzeichnet, 
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dafi die Signalisierungs-Einheit (SU) dazu ausgelegt ist, 
durch ein von ihr erzeugtes Meldesignal (READY, INT1, INT2) 
zu signalisieren, dafi eine im Hardware-Block wiederholt aus- 
zufiihrende Operation oder Operationsf olge eine gewiinschte 
5 Anzahl von Malen ausgef iihrt wurde . 



11. Konf igurierbarer Hardware-Block nach einem der Anspriiche 
8 bis 10, 

dadurch gekennzeichnet, 
10 daft die Signalisierungs-Einheit (SU) dazu ausgelegt ist, bei 
Bedarf ein als Interrupt Request fiir eine programmgesteuerte 
Einheit verwendbares Meldesignal (READY, INT1, INT2) zu gene- 
rieren . 



15 12. Konf igurierbarer Hardware-Block nach einem der Anspriiche 
8 bis 11, 

dadurch gekennzeichnet, 

daft das Meldesignal (READY, INT1, INT2) das Ausgangssignal 
mindestens einer Vergleichs-Einheit (CUB; CUB1, CUB2, CUB3) 



13. Konf igurierbarer Hardware-Block nach Anspruch 12, 
dadurch gekennzeichnet, 

daft die Vergleichs-Einheiten (CUB; CUB1, CUB2, CUB3) zumin- 
25 dest teilweise konf igurierbare Vergleichs-Einheiten sind, die 
eingegebene Signale auswahlbaren Vergleichsoperationen und/- 
oder Oberpruf ungen auf WAHR und/oder UNWAHR unterziehen 
konnen . 



30 14. Konf igurierbarer Hardware-Block nach Anspruch 13, 
dadurch gekennzeichnet, 

daft die auswahlbaren Vergleichsoperationen Grofter-, Grofter/- 
Gleich-, Gleich-, Ungleich-, Kleiner-, und/oder Kleiner/- 
Gleich-Vergleiche umfassen . 
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15. Konf igurierbarer Hardware-Block nach einem der Anspruche 
12 bis 14, 

dadurch gekennzeichnet, 

dafl den Vergleichs-Einheiten (CUB; CUB1, CUB2 , CUB3) zumin- 
5 dest teilweise eingangsseitig ein Multiplexer (MUXA4) vor- 
geschaltet ist, durch des festlegbar ist, welche Signale den 
Vergleichs-Einheiten als Eingangssignale zugefiihrt werden. 

16. Konf igurierbarer Hardware-Block nach einem der vorher- 
10 gehenden Anspruche, 

dadurch gekennzeichnet, 
> daft der konf igurierbare Hardware-Block f unktionsmaftig kon- 
figurierbare Teileinheiten (AUx, CUx, DEMUX, MUXx) und/oder 
konf igurierbare Daten- und/oder Signalpfade aufweist. 

15 

17. Konf igurierbarer Hardware-Block nach Anspruch 16, 
dadurch gekennzeichnet, 

daft konf igurierbare Daten- und/oder Signalpfade zur externen 
Hardware existieren oder herstellbar sind. 

20 

18. Konf igurierbarer Hardware-Block nach einem der vorher- 
gehenden Anspruche, 

dadurch gekennzeichnet, 
dafl die Speichereinrichtung (44) ein eine Vielzahl von 
25 Registern umfassender Registerblock ist. 

19. Konf igurierbarer Hardware-Block nach einem der vorher- 
gehenden Anspruche, 

dadurch gekennzeichnet, 
30 daft der Hardware-Block basierend auf Befehlen oder Befehls- 
folgen konf igurierbar ist, so dali er die durch die Befehle 
oder Bef ehlsf olgen vorgegebenen Operationen oder Operations- 
folgen ausfiihren kann. 
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20. Konf igurierbarer Hardware-Block nach Anspruch 19, 
dadurch gekennzeichnet, 
daB der Hardware-Block so dimensioniert ist, dafl dessen 
figurierung hyperblockweise erfolgen kann. 
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Zusammenf as sung 

Konf igurierbarer Hardware-Block 

Es wirci ein konf igurierbarer Hardware-Block beschrieben, der 
dazu ausgelegt ist, abhangig von seiner Konf iguration in ei- 
ner Speichereinrichtung (44) gespeicherte Daten auszulesen, 
die ausgelesenen Daten arithmetisch und/oder logisch zu ver- 
arbeiten, und das Ergebnis der Verarbeitung reprasentierende 
Daten in die Speichereinrichtung einzuschreiben . Der be- 
schriebene Hardware-Block zeichnet sich dadurch aus, daft er 
in die Lage versetzbar ist, mit externer Hardware zu inter- 
agieren. Dadurch erhalt man einen flexibel und universell 
e inset zbar en Hardware-Block. 



Figur 1 
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Bezugszeichenliste 

1 predecode unit 

2 instruction buffer 

5 3 decode, rename & load unit 

4 s-unit 

5 data cache 

6 memory interface 

41 programmable structure buffer 

10 42 functional unit with programmable structure 

43 integer/address instruction buffer 

44 integer register file 
AUx arithmetische Einheit 

CUA Vergleichs-Einheit des ersten Typs 

15 CUBx Vergleichs-Einheit des zweiten Typs 

DEMUX Demultiplexer 

MUXAx Multiplexer des ersten Typs 

MUXB Multiplexer des zweiten Typs 

TGU Taktgenerierungs-Einheit 

20 SU Signalisierungs -Einheit 

MCLK Master-Takt 

ENABLE Enable-Signal 

ADC_READY Ready-Signal eines A/D-Wandlers 

CLK von TGU erzeugtes Taktsignal 

25 READY Ready-Signal des Hardware-Blocks 

INT1 Interrupt Request 1 des Hardware-Blocks 

INT2 Interrupt Request 2 des Hardware-Blocks 

LPL Load- Pipe line 

SPL Store- Pipe line 

30 A Adressen 

D Daten 
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